sys_config is a "subscription-based data storage API"

It has the concept of services and listeners. Services provide data, listeners subscribe to registration/unregistration events from specific services.

Services are divided into two classes: LV2 services (positive service IDs) and User services (negative service IDs).
LV2 services seem to be implictly "available", probably constructed on-demand with internal LV2 code generating the data. An example is PadManager (service ID 0x11).
User services may be registered through a syscall, and have negative IDs. An example is libPad (service ID 0x8000'0000'0000'0001).
Note that user-mode *cannot* register positive service IDs.

To start with, you have to get a sys_config handle by calling sys_config_open and providing an event queue.
This event queue will be used for sys_config notifications if a subscribed config event is registered.

With a sys_config handle, listeners can be added to specific services using sys_config_add_service_listener.
This syscall returns a service listener handle, which can be used to close the listener and stop further notifications.
Once subscribed, any matching past service registrations will be automatically sent to the supplied queue (thus the "data storage").

Services exist "implicitly", and data may be registered *onto* a service by calling sys_config_register_service.
You can remove config events by calling sys_config_unregister_service and providing the handle returned when registering a service.

If a service is registered (or unregistered) and matches any active listener, that listener will get an event sent to the event queue provided in the call to sys_config_open.

This event will contain the type of config event ("service event" or "IO event", in event.source),
the corresponding sys_config handle (event.data1), the config event ID (event.data2 & 0xffff'ffff),
whether the service was registered or unregistered ('data2 >> 32'), and what buffer size will be needed to read the corresponding service event (event.data3).

NOTE: if multiple listeners exist, each gets a separate event ID even though all events are the same!

After receiving such an event from the event queue, the user should allocate enough buffer and call sys_config_get_service_event
(or sys_config_io_event) with the given event ID, in order to obtain a sys_config_service_event_t (or sys_config_io_event_t) structure
with the contents of the service that was (un)registered.